Seven Words You Can Never Use in a Requirements Specification

Fri, 17 Oct 2008 00:22:00 GMT

This is the text of a presentation my boss had attended at a Telelogic conference and which, she later shared with the BA team at work. It lists specific words that when used in requirements, compromise the quality of the very requirements. I'll let the article describe further. Looking forward to some feedback...Les, thanks for your wisdom.

SEVEN WORDS YOU CAN NEVER USE IN A REQUIREMENTS SPECIFICATION
Les Grove
Tektronix, Inc.

Prepared for the 2006 Telelogic Americas User Group Conference

A requirement specification is the one place where all of the stakeholders involved with a project have a vested interest. Unfortunately, requirements are often not written clearly for the people who depend on them. This [article] will help people to use precise language in writing their requirements, detect problems when reviewing requirements, and avoid misunderstandings when using requirements.
The seven bad words referenced in the title were selected from real Tektronix specifications in various forms of readiness (draft, pre-review, post-review, released). Each word is representative of a particular type of word.

The Seven Bad Words

#7 Always
The problem with this word is that it implies certainty, but can never be verified. How does one verify that “Values shall always be available”? Similar words include all, every, and never.

#6 Some
This term is just plain vague and can thus be interpreted a number of ways. When a requirement states that “There will be some restrictions on changes a user can make,” this leaves it up to the designer to either spend time talking with the author or guessing at what the restrictions should be. Similarly vague words include most, sometimes, and usually.

#5 Appropriate
This is a vague adjective that indicates that the requirement has not been thoroughly considered. An author may think that anyone would understand “Put up an appropriate message when there are no more available slots,” but this type of use could indicate something more problematic. What is the real requirement here? There needs to be an indication that there are no available slots, but the author dabbled into design by stating that the solution is some sort of message—and just didn’t want to specify the message. So, in this example, a more basic problem is uncovered by catching the vague adjective. Other adjectives to watch out for include easy, user-friendly, fast, and graceful.

#4 Handle
Vague verbs such as this do not describe what the system will actually do. It is a sign that the author has thrown up their hands in frustration because the system should do something in a given situation, but can’t decide what. When a requirement states that “The application must handle suppressed data,” the designer has nothing to base any design decisions on. Similar words include improve, provide, reject, and support.

#3 Etc.
Words like this indicate two problems. First, there is an incomplete requirement that leaves the designer to complete the list. “The user shall be notified of loss of signal, loss of clock, etc.” indicates that there are other states and conditions that the user should be notified about, but are not specified. The second problem with statements like this is that there are usually multiple requirements in the single statement that need to be separated out. Similar words are another, other, including, not limited to, and such as.

#2 It
Pronouns in requirement statements can be very clear to the author, but misleading to the readers. The statement “Touch screen operations provide audio feedback. User can turn it on or off’” does not indicate whether it refers to the touch screen or the audio feedback. Also, it indicates that there are two requirements: audio feedback and some sort of switching capability. Simply separating the two sentences in this example does not solve any problems either because the second sentence totally loses its context due to the pronoun. The word this is another pronoun to avoid.

#1 Should
At Tektronix, this word is the worst offender, as it is used more frequently than any of the other words in this list. This opinion goes against some other requirements books and the practices of some very large companies (particularly defense and finance), but Tektronix relies on DOORS attributes to indicate requirement priority. Because it implies uncertainty, testers cannot be sure there is an error if the negative occurs. When a requirement states that “The default should be auto-detection,” is it an error during testing if the default is something else? Other uncertain words are and/or, can, could, if possible, and may.

An Inquiry into the Roles of the BA and the BSA

Thu, 18 Oct 2007 00:15:00 GMT

How do we define the role of a BA. Is there a difference in responsibilities executed by a business analyst and business systems analyst? Or, are the titles simply synonymous with each other? Attempting to clear out some of that fog is the purpose of this article. As much as I enjoyed writing this, I also look forward to receiving your feedback and thoughts…keep the flow of information going.

An Inquiry into the Roles of the BA and the BSA

Firstly, I don’t believe the two terms mean the same thing; they are different roles, albeit entailing some very common responsibilities. The terms are used interchangeably all too often (I for one am guilty of that), implying the absence of distinction between the two roles. In actuality, the bigger picture shows a few, not a lot, but handful of noticeable differences. And sure, there might be more differences that I have not uncovered.

The way I went about determining the difference was to go on to Dice, and randomly pick out independent samples of the “business analyst” vacancies. I picked 30 of them – a minute sample size considering the greater population of 12,000+ vacancies. And I did the same for the “business systems analyst” job title. I examined the descriptions of all 30 posts in both groups, and documented and analyzed them (here, analysis wouldn’t have been possible before structured documentationJ).

Again, let me remind you of some pointers:

I picked out only those ads that said “business analyst” and “business systems analyst” as the Job Title and no other variations.
Ads were picked randomly, meaning I clicked on the ad without much thought, except the one above.
The one thought I did give was to make sure I wasn’t picking ads by the same recruiter (and it turned out neither of the samples had repetitions after all). Each ad was independent of the rest.

The summaries of the two groups have been attached below.

Apart from the commonalities that the two roles share (which is common knowledge), here’s what I found the differences to be:

At least 6 out of 10 business analyst positions require the candidate to have a good deal of project management knowledge, and will be expected to wear that hat as part of the of the responsibilities. This is a preferred skill for a minority of recruiters, for the rest it’s required. This area has major emphasis when BA’s are sought; they have to rise to leadership in the same position. Whereas for the business systems analyst, only four ads that mentioned project management skills. And even if they did, it was a preferred skill, not a required one.

More than BSA’s, BA’s are expected to have OOAD experience.

BA’s are expected to provide training to users, not just demos of the software developed. (I wasn’t expecting this; I’ve worked in places where a separate training dept. would take care of that.)

Experience with the UML was of greater demand from BSA’s than from BA’s.

BSA recruiters placed considerable emphasis on experience with Oracle and SQL, and design of relational databases. It’s almost like what project management is to the BA, SQL is to the BSA.

More than BA ads, BSA positions, albeit assorted, required knowledge of or experience with technologies like XML, Java, and UNIX.

In conclusion, except for # 3, the other differences couldn’t have been just coincidence in 30 distinct job ads. I think they are real differences and I’m sure there are a few more out there.

Attachments:

Summary of the BA ad

Summary of the BSA ad

Business Analyst Community & Resources | Modern Analyst

Seven Words You Can Never Use in a Requirements Specification

An Inquiry into the Roles of the BA and the BSA